Feature: TPM2 Support #4337
Feature: TPM2 Support #4337
Conversation
Co-Authored-By: Amos Treiber <[email protected]>
| bool not_zero_64(std::span<const uint8_t> in) { | ||
| Botan::BufferSlicer bs(in); | ||
|
|
||
| while(bs.remaining() > 8) { | ||
| if(Botan::load_be(bs.take<8>()) == 0) { | ||
| return false; | ||
| } | ||
| } | ||
| // Ignore remaining bytes | ||
|
|
||
| return true; | ||
| } |
There was a problem hiding this comment.
There was an open discussion in the previous PR where Jack pointed out that this could fail randomly with a 1/2^64 probability.
| using TPM2_HANDLE = uint32_t; | ||
|
|
||
| /// Forward declaration of TSS2 type for convenience | ||
| using ESYS_TR = uint32_t; |
There was a problem hiding this comment.
Do these need to be in the global namespace?
There was a problem hiding this comment.
Mhh, when including the TSS headers they won't be namespaced either. As stated further below: #4337 (comment).
| #include <botan/exceptn.h> | ||
|
|
||
| /// Forward declaration of TSS2 type for convenience | ||
| using TSS2_RC = uint32_t; |
There was a problem hiding this comment.
These forward declares and "forward typedefs" are a bit dirty anyway, as they will cause trouble if the TSS would ever change their underlying types (obviously). I'm fairly confident that they won't do that, given that this API is standardized and agreed upon by the TCG.
We chose to put them into global namespace, because they are (or will be) in global namespace in the TSS headers as well. Moving them into Botan::TPM2 would be possible, I think. No strong opinion on that, to be honest.
That said: Perhaps it would be a good idea to move all those forward declares into a dedicated header (say: tpm2_forward_declares.h).
Right now that doesn't really make sense. But once ECC keys are added, users could build with TPM support but omit RSA entirely, if they wish to do so. Or vice versa. |
reneme
force-pushed
the
feature/tpm2_support
branch
from
c354200
to
18a9a16
Compare
@randombit Thanks! I addressed your comments. We're currently working on support for ECDSA (and ECDH for the crypto backend) -- here. We could add this here or apply it as a separate PR once this is merged. In any case, it would be great if this level of TPM2 support would make it into 3.6.0. |
Installs swtpm on the CI build machines to simulate a TPM 2.0 chip and adds infrastructure to pass TPM-related parameters to the unit test binary. Also adds an empty tpm2 module that can be enabled by configuring with ./configure.py --with-tpm2 Co-Authored-By: René Meusel <[email protected]>
Namely:
* TPM2::Context - allowing to request basic authorative information
* TPM2::Session - to create an unauth'ed HMAC session with the TPM
* TPM2::Error - Botan exception encapsulation TPM-related errors
* TPM2::Object - handles the lifetime of TPM object handles
* tpm2_util.h - utility functions to handle calls to ESYS API
* tpm2_algo_mappings.h - mappings from Botan algo strings to TSS'
algorithm IDs and scheme definitions
Note, that some of those things aren't actively used in this commit, yet.
Co-Authored-By: René Meusel <[email protected]>
Co-Authored-By: René Meusel <[email protected]>
reneme
force-pushed
the
feature/tpm2_support
branch
from
18a9a16
to
0198e61
Compare
Along with the actual asymmetric algorithm support this adds a number of required auxiliaries. Most notably, TPM2::HashFunction is an internal class exposing the TPM's hashing functionality as a Botan::HashFunction. 'Restricted' keys must use this to obtain a token from the TPM proofing that the data was hashed (and validated) by the TPM. The RSA adapter is stashed into the 'tpm2_rsa' submodule so that RSA support can be disabled at compile time. To facilitate the addition of ECC keys, an abstract TPM2::PrivateKey class is always part of the main TPM2 module. Asymmetric keys can be created, loaded, persisted and evicted as needed. Finally, asymmetric keys (on the TPM) may now be used to establish authenticated sessions. Co-Authored-By: René Meusel <[email protected]>
This adds an implementation of the tpm2-tss crypto callbacks. If enabled, Botan will be used for the client-side crypto functions to communicate with the TPM. This lets applications shed a transitive dependency on another crypto library (like OpenSSL or mbedTLS). The crypto callbacks are available in tpm2-tss 4.0 and later. Before that, calling TPM2::Context::use_botan_crypto_backend() will result in an exception. Co-Authored-By: René Meusel <[email protected]>
Co-Authored-By: Amos Treiber <[email protected]>
reneme
force-pushed
the
feature/tpm2_support
branch
from
0198e61
to
51fd5dd
Compare
Included in the Pull Request
This introduces an initial integration with TPM 2.0 (#3877) with the following functionality:
TPM2::ContextTPM2::SessionTPM2::RandomNumberGeneratorTPM2::PublicKey,TPM2::PrivateKeyTPM2::HashFunctiontpm2_rsatpm2_crypto_backendAlso, we added documentation describing the basics of the TPM 2 wrapper.
Design Rationale
The wrapper is designed to seamlessly integrate TPM2 into Botan, i.e., one can always use the provided functionalities in Botan without detailed knowledge about the underlying TPM Software Stack (TSS). If, however, the user wants more fine-grained control, they can use the TSS directly to set up objects and then pass their handles into the Botan wrappers. For instance, a custom "policy session" could be defined that way and then passed into Botan's key pair wrappers via the introduced
Botan::TPM2::Sessionwrapper to access a key that was configured externally. To enhance readability for these cases, the required input types from the TSS have been forward declared (as opposed to genericvoid*/uint32_tinput types introduced in #4117 that is superceded by this PR).Future Work
Limitations of the TPM wrapper
The current state of the implementation covers the TPM's functionality only partially. Below is a non-exhaustive list of limitations and potential future work:
TPM2::ECC_PublicKey/TPM2::ECC_PrivateKey(in a new moduletpm2_ecc)get_ecdh_point())